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REISSUE PATENT APPLICATION 
IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



In re the Reissue Application of: 
C. J. MONAHAN, et al. 



-U.S. Patent No, 

Granted 

For 



5,388,260 

February 7, 1995 

TRANSPARENT LIBRARY MANAGEMENT 



REISSUE DECLARATION AND POWER OF ATTORNEY 

BOX 7 

Assistant Commissioner of Patents 
Washington, D.C. 20231 

Sir: 

Christopher J. Monahan, Mary L. Monahan, Dennis L. Willson, 
and Lee D. Willson, citizens of the United States of America and 
residing at the following address: 

Christopher J. Monahan Mary L. Monahan 

399 SW 3rd St. 399 SW 3rd St. 

Boca Raton, FL 33432 Boca Raton, FL 33432 



Dennis L. Willson 
555 Lanfair Circle 
San Jose, CA 95136 



Lee D. Willson 
431 Lily Ann Way 
San Jose, CA 95123 



declare as follows: 



1. The entire title and legal interest in and to U.S. 
Patent Application Serial No. 07/526,257 and United States Patent 
No. 5,388,260 (hereinafter '260 patent) granted to Monahan et al. 
on February 7, 1995, upon such application, was conveyed to IBM 
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Corporation ("IBM"). IBM is presently the owner of record of the 
f 260 patent. 

* 

2. We have reviewed and understand the contents of the 
specification and claims of the accompanying application for 
reissue. 

3* We verily believe ourselves to be the original sole 
inventors of the invention described and claimed in the f 260 
patent and in the specification and claims of the accompanying 
application for which we solicit a reissue patent. 

4. We acknowledge the duty of each individual associated 
with the filing and prosecution of the reissue application to 
disclose information known to that individual to be material to 

* patentability as defined in 37 C.F.R. § 1.56. 

5. We verily believe the "260 patent to be partly 
inoperative, or invalid, by reason of the patentees' claiming 
less than they had a right to claim, particularly in failing to 
present claims of the scope represented by reissue claims 5-9 in 
this application. 

6. As described in the 9 260 patent, the invention is 
directed to an apparatus and method for providing transparent 
library management within a data storage system. The data 
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storage system consists of a host processor, an automated storage 
library, and a controller. The automated storage library 
contains storage drives for reading and/or writing data onto 
removable data storage media, storage cells for storing the 
removable data storage media, and an automated means for 
transferring the removable data storage media between the storage 
cells and the storage drives. Data is stored in files, with the 
files grouped into volumes, and the volumes stored on the data 
storage media. The host processor requests a file to be accessed 
by specifying the volume and the library. The controller 
receives the request and determines the location of the file 
within the library. The controller allocates a storage drive and 
instructs the automated means to transfer the specified volume 
from the storage cell to the allocated storage drive. The host 
processor then accesses the data within in the file, unaware of 
which storage drive the volume is mounted, such that the storage 
drives are transparent to the host processor. The invention 
allows the host processor to access a file within the automated 
storage library as if accessing a file on a single peripheral 
storage drive, with the specification of the storage drive and 
the subdirectory replaced by the specification of the library and 
the volume. 

7. Patent claim 1 is a method for performing transparent 
library management. Claim 1 describes accessing data from a 
selected file within the library such that the storage drives are 
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transparent to the host processor using five method steps. It 
has come to the attention of the assignee that claim 1 contains 
limitations which are not essential to performing transparent 
library management as described in the patent specification. In 
particular, patent claim 1 describes a controller included within 
the automated storage library. Claim 1 recites in the preamble, 
• "the automated storage library including a plurality of internal 
peripheral storage drives, a plurality of storage cells, 
automated means for transferring a data storage medium between 
the plurality of internal peripheral storage drives and the 
plurality of storage cells, and a controller coupled to each of 
the plurality of internal peripheral storage drives, the 
automated means, and a host processor." The method can operate, 
however, without having the controller located within the 
automated storage library. 

* 

8. The reissue application presents claim 5 as generally 
corresponding to patent claim 1. Reissue claim 5 does not 
include the limitation that the controller be contained within 
the automated storage library. Reissue claim 5 describes a data 
storage subsystem consisting of an automated storage library and 
a controller, wherein the controller is located between a host 
processor and the library. Reissue claim 5 recites "a data 
storage subsystem having an automated storage library and a 
controller", wherein the library includes "a plurality of storage 
drives", "a plurality of storage cells", and "an automated 
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means," Reissue claim 5 further recites "said controller coupled 
to each of said storage drives, said automated means, and a host 
processor." In addition, reissue claim 5 rephrases the preamble 
to enhance the clarity of the claim. Reissue claim 6 depends 
from reissue claim 5 and generally corresponds to patent claim 2. 

9. Claim 3 of the *260 patent is directed generally to an 
apparatus for providing transparent library management. Patent 
claim 3 describes an automated storage library for accessing data 
in a file such that peripheral storage drives within the library 
used for such data access are transparent to a host processor 
requesting such data access. This claim also contains 
limitations which are not essential to providing transparent 
library management as described in the patent specification. As 
with patent claim 1, patent claim 3 describes a controller 
included within the automated storage library. Claim 3 recites 
the following elements: "a plurality of internal peripheral 
storage drives", "a plurality of storage cells", "an automated 
means", and "a controller." The controller is "coupled to each 
of the plurality of internal peripheral storage drives, the 
automated means, and the host processor." The invention can 
operate, however, without having the controller located within 
the automated storage library. 

10. Reissue claim 7 generally corresponds to patent claim 3 
without the aforementioned limitation that the controller be 
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located within the automated storage library. Reissue claim 7 
describes a data storage subsystem consisting of an automated 
storage library and a controller, wherein the controller is 
located between a host processor and the library. Reissue claim 
7 recites "a data storage subsystem" comprising "an automated 
storage library" and "a controller"/ wherein the library includes 
"a plurality of peripheral storage drives", "a plurality of 
storage cells", and "an automated means." Reissue claim 5 
further recites that the controller is "coupled to each of said 
storage drives, said automated means, and said host processor." 
In addition, reissue claim 8 depends from reissue claim 7 and 
generally corresponds to patent claim 4. 

11. In addition to the insufficiency of patent claims 1 and 
3 as previously described, the '260 patent fails to claim a 
computer program product as entitled by the scope of the patent 
application. A recently decided case involving the Assignee has 
led to the allowance of a new class of claims, typically referred 
to as computer program product claims. In re Beauregard , App. 
No. 95-1054 (Fed. Cir. 1995). In In re Beauregard , the 
Commissioner of Patents and Trademarks has now concluded that 
computer programs embodied in a tangible medium are patentable 
subject matter under 35 U.S.C. §101 and must be examined under 35 
U.S.C. §§102, 103. 
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12. Reissue claim 9 describes a computer program product, 
or article of manufacture, for use in a data storage subsystem 
providing transparent library management. Reissue claim 9 
recites "an article of manufacture for use in a data storage 
subsystem having an automated storage library and a controller, 
said data storage subsystem for accessing data in a file on one 
of a plurality of volumes stored within said library such that 
peripheral storage drives within said library are transparent to 
a host processor." Reissue claim 9 further recites "said article 
of manufacture comprising a computer usable storage medium having 
a computer readable program code embodied in said medium." 

13. The presence of unnecessary limitations in claims 1 and 
3, and the failure to include a computer program product claim, 
were first called to our attention at the time that this reissue 
application was filed. Prior to that time, the inventors were 
unaware of the significance of these limitations or the potential 
limiting affect thereof. The inventors believe that these errors 
arose from the failure of the attorney originally prosecuting 
this patent to recognize and appreciate the full scope of the 
invention. Upon information and belief, these errors arose 
without any deceptive intention on the part of any individual 
associated with the filing and prosecution of the f 260 patent* 

14 . This declaration is accompanied by an order of a title 
report as required by 37 C.F.R. §1.178. 
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15. This declaration is also accompanied by assignee's 
assent to the filing of the attached reissue application and by 
the assignee's offer to surrender the original Letters Patent as 
required by 37 C.F.R- § 1.178. 

16. We appoint the following as our attorneys or agents 
with full power of substitution to prosecute the attached reissue 
application and to transact all business in the Patent and 
Trademark Office connected therewith. 



Philip R. Wadsworth (#29,219) 
Leslie G. Murray (#31,183) 
Esther E- Klein (#34,337) 
Douglas R. Millett (#31,784) 
Noreen A. Krall (#39,734) 
Christopher A. Hughes (#26,914) 
John E. Hoel (#26,279) 



Robert M. Sullivan (#39,391) 
Ingrid M. Foerster (#36,511) 
6. Marlin Knight (#33,409) 
Paik Saber (#37,494) 
Joseph C. Redmond, Jr. (#18,753) 
Edward A* Pennington (#32,588) 



17. Correspondence in connection with the attached reissue 

application should be addressed to: 

Robert M. Sullivan 
IBM Corporation 
Intellectual Property Law 
9000 S. Rita Road 
Tucson, AZ 85744 
(520) 799-2550 



18. The undersigned petitioners declare further that all 
statements made herein of our own knowledge are true and that all 
statements made on information and belief are believed to be 
true; and further that these statements were made with the 
knowledge that willful false statements or the like so made are 
punishable by fine or imprisonment, or both, under Section 1001 
of Title 18 of the United States Code and that such willful false 
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statements may jeopardize the validity of the application or any 
patent issuing thereon. 



Dated : 



Dated : d/ll 
1: 



Dated: 



Dated : <f f%9.\ 

RMS/cw 



By 



Christopher J. Monahan 
By: 

V %* Monahan - 
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REISSUE PATENT APPLICATION 
IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



In re the Reissue Application of: 
C. J. MONAHAN, et al. 



U.S. Patent No. 

Granted 

For 



5,388,260 

February 7, 1995 

TRANSPARENT LIBRARY MANAGEMENT 



REISSUE DECLARATION AND POWER OF ATTORNEY 



BOX 7 

Assistant Commissioner of Patents 
Washington, D.C. 20231 

Sir: 

Christopher J. Monahan, Mary L. Monahan, Dennis L. Willson, 
and Lee D. Willson, citizens of the United States of America and 
residing at the following address: 



ChristopJigr J. Monahan 
'399 SW 3rd St. 
Boca Raton, FL 33432 

Dennis L. Willson 
555 Lanfair Circle 
San Jose, CA 95136 



Mary L. Monahan 

399 SW 3rd St. 

Boca Raton, FL 33432 



Lee D. Willson 
431 Lily Ann Way 
San Jose, CA 95123 



declare as follows: 



1. The entire title and legal interest in and to U.S. 
Patent Application Serial No. 07/526,257 and United States Patent 
No. 5,388,260 (hereinafter '260 patent) granted to Monahan et al. 
on February 7, 1995, upon such application, was conveyed to IBM 



Corporation ("IBM"). IBM is presently the owner of record of the 
'260 patent. 

2. We have reviewed and understand the contents of the 
specification and claims of the accompanying application for 
reissue. 

3. We verily believe ourselves to be the original sole 
inventors of the invention described and claimed in the '260 
patent and in the specification and claims of the accompanying 
application for which we solicit a reissue patent. 

4. We acknowledge the duty of each individual associated 
with the filing and prosecution of the reissue application to 
disclose information known to that individual to be material to 
patentability as defined in 37 C.F.R. § 1.56. 

5. We verily believe the f 260 patent to be partly 
inoperative, or invalid, by reason of the patentees* claiming 
less than they had a right to claim, particularly in failing to 
present claims of the scope represented by reissue claims 5-9 in 
this application. 

6. As described in the '260 patent, the invention is 
directed to an apparatus and method for providing transparent 
library management within a data storage system. The data 
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storage system consists of a host processor, an automated storage 
library, and a controller. The automated storage library 
contains storage drives for reading and/or writing data onto 
removable data storage media, storage cells for storing the 
removable data storage media, and an automated means for 
transferring the removable data storage media between the storage 
cells and the storage drives. Data is stored in files, with the 
files grouped into volumes, and the volumes stored on the data 
storage media. The host processor requests a file to be accessed 
by specifying the volume and the library. The controller 
receives the request and determines the location of the file 
within the library. The controller allocates a storage drive and 
instructs the automated means to transfer the specified volume 
from the storage cell to the allocated storage drive. The host 
processor then accesses the data within in the file, unaware of 
which storage drive the volume is mounted, such that the storage 
drives are transparent to the host processor. The invention 
allows the host processor to access a file within the automated 
storage library as if accessing a file on a single peripheral 
storage drive, with the specification of the storage drive and 
the subdirectory replaced by the specification of the library and 
the volume. 

7. Patent claim 1 is a method for performing transparent 
library management. Claim 1 describes accessing data from a 
selected file within the library such that the storage drives are 
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transparent to the host processor using five method steps. It 
has come to the attention of the assignee that claim 1 contains 
limitations which are not essential to performing transparent 
library management as described in the patent specification. In 
particular, patent claim 1 describes a controller included within 
the automated storage library. Claim 1 recites in the preamble, 
"the automated storage library including a plurality of internal 
peripheral storage drives, a plurality of storage cells, 
automated means for transferring a data storage medium between 
the plurality of internal peripheral storage drives and the 
plurality of storage cells, and a controller coupled to each of 
the plurality of internal peripheral storage drives, the 
automated means, and a host processor." The method can operate, 
however, without having the controller located within the 
automated storage library. 

8. The reissue application presents claim 5 as generally 
corresponding to patent claim 1. Reissue claim 5 does not 
include the limitation that the controller be contained within 
the automated storage library. Reissue claim 5 describes a data 
storage subsystem consisting of an automated storage library and 
a controller, wherein the controller is located between a host 
processor and the library. Reissue claim 5 recites "a data 
storage subsystem having an automated storage library and a 
controller", wherein the library includes "a plurality of storage 
drives", "a plurality of storage cells", and "an automated 
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means." Reissue claim 5 further recites "said controller coupled 
to each of said storage drives, said automated means, and a host 
processor." In addition, reissue claim 5 rephrases the preamble 
to enhance the clarity of the claim. Reissue claim 6 depends 
from reissue claim 5 and generally corresponds to patent claim 2. 

9. Claim 3 of the '260 patent is directed generally to an 
apparatus for providing transparent library management. Patent 
claim 3 describes an automated storage library for accessing data 
in a file such that peripheral storage drives within the library 
used for such data access are transparent to a host processor 
requesting such data access. This claim also contains 
limitations which are not essential to providing transparent 
library management as described in the patent specification. As 
with patent claim 1, patent claim 3 describes a controller 
included within the automated storage library. Claim 3 recites 
the following elements: "a plurality of internal peripheral 
storage drives", "a plurality of storage cells", "an automated 
means", and "a controller." The controller is "coupled to each 
of the plurality of internal peripheral storage drives, the 
automated means, and the host processor." The invention can 
operate, however, without having the controller located within 
the automated storage library. 

10. Reissue claim 7 generally corresponds to patent claim 3 
without the aforementioned limitation that the controller be 
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located within the automated storage library. Reissue claim 7 
describes a data storage subsystem consisting of an automated 
storage library and a controller, wherein the controller is 
located between a host processor and the library. Reissue claim 
7 recites l! a data storage subsystem" comprising "an automated 
storage library 11 and "a controller", wherein the library includes 
"a plurality of peripheral storage drives", "a plurality of 
storage cells", and "an automated means." Reissue claim 5 
further recites that the controller is "coupled to each of said 
storage drives, said automated means, and said host processor." 
In addition, reissue claim 8 depends from reissue claim 7 and 
generally corresponds to patent claim 4. 

11. In addition to the insufficiency of patent claims 1 and 
3 as previously described, the '260 patent fails to claim a 
computer program product as entitled by the scope of the patent 
application. A recently decided case involving the Assignee has 
led to the allowance of a new class of claims, typically referred 
to as computer program product claims. In re Beauregard , App. 
No. 95-1054 (Fed. Cir. 1995). In In re Beauregard , the 
Commissioner of Patents and Trademarks has now concluded that 
computer programs embodied in a tangible medium are patentable 
subject matter under 35 U.S.C. §101 and must be examined under 35 
U.S.C. §§102, 103. 
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12. Reissue claim 9 describes a computer program product, 
or article of manufacture, for use in a data storage subsystem 
providing transparent library management. Reissue claim 9 
recites "an article of manufacture for use in a data storage 
subsystem having an automated storage library and a controller, 
said data storage subsystem for accessing data in a file on one 
of a plurality of volumes stored within said library such that 
peripheral storage drives within said library are transparent to 
a host processor." Reissue claim 9 further recites "said article 
of manufacture comprising a computer usable storage medium having 
a computer readable program code embodied in said medium." 

13. The presence of unnecessary limitations in claims 1 and 
3, and the failure to include a computer program product claim, 
were first called to our attention at the time that this reissue 
application was filed. Prior to that time, the inventors were 
unaware of the significance of these limitations or the potential 
limiting affect thereof. The inventors believe that these errors 
arose from the failure of the attorney originally prosecuting 
this patent to recognize and appreciate the full scope of the 
invention. Upon information and belief, these errors arose 
without any deceptive intention on the part of any individual 
associated with the filing and prosecution of the '260 patent. 

14. This declaration is accompanied by an order of a title 
report as required by 37 C.F.R. §1.178. 
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15. This declaration is also accompanied by assignee's 
assent to the filing of the attached reissue application and by 
the assignee's offer to surrender the original Letters Patent as 
required by 37 C.F.R. § 1.178. 

16. We appoint the following as our attorneys or agents 
with full power of substitution to prosecute the attached reissue 
application and to transact all business in the Patent and 
Trademark Office connected therewith. 



Philip R. Wadsworth (*29,219L_ 
Leslie G. Murray tf3JU183.) , 
Esther E. Klein (*34 .337) 
Douglas R- Millett (#3X^784^ — 
Noreen A. Krall (t39,X3JL)u~- 
Christopher A. Hughes^XflfijjaiA^- 
John E. Hoel (»2 &r279) 



Robert M. Sullivan (#39,391) 

Ingrid M. Foerster 

G. Marlin Knight L#33U4Q9X_ 

Paik Saber ( #3#y-494) * 

Joseph C. Redmond, Jr. £#JLa,JL53-)„ 
Edward A. Pennington (#32,588) v 



17. Correspondence in connection with the attached reissue 
application should be addressed to: 

Ro bert M. Sullivan 

IBM C orporation 

JntelTectual Property Law_, 

9000 ^ S. Rita Road 
jTucspn^AZ — %S3£A-± 
" (520) 799-2550 

18. The undersigned petitioners declare further that all 
statements made herein of our own knowledge are true and that all 
statements made on information and belief are believed to be 
true; and further that these statements were made with the 
knowledge that willful false statements or the like so made are 
punishable by fine or imprisonment, or both, under Section 1001 
of Title 18 of the United States Code and that such willful false 
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statements may jeopardize the validity of the application or any 
patent issuing thereon. 

Dated: By: 

Christopher J. Monahan 

Dated: By: 

Mary L. Monahan 

Dated: By: 

Dennis L. Willson 

Dated: By: 

Lee D. Willson 

RMS/cw 
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ment. To access a file in the library, a requester need 
only specify the volume on which the file is located, 
permitting the use of a standard file access method for a 
single peripheral storage device. A path format which is 
the same as that used for a single, peripheral storage 
device, except that the peripheral storage device desig- 
nator is replaced with a designator for the automated 
storage library and a volume label is inserted as a subdi- 
rectory path element, and a program product therefor 
are also disclosed. 
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BACKGROUND OF THE INVENTION 

1. Field of the Invention 

This invention relates to an automated storage library 
for which management thereof is transparent to a host 10 
processor, and a program product and path format 
therefor. More particularly, the automated storage li- 
brary appears to the host processor the same as does a 
single, peripheral storage device. 

2. Description of the Related Art 15 
Modern computers require a host processor including 

one or more central processing units and a memory 
facility. The processor manipulates data stored in the 
memory according to instructions provided to it. The 
memory must therefore be capable of storing data re- 2CJ 
quired by the processor and transferring that data to the 
processor at a rate capable of making the overall opera- 
tion of the computer feasible. The cost and performance 
of computer memory is thus critical to the commercial 
success of a computer system. 

Because today's computers require large quantities of 
data storage capacity, computer memory is available in 
many forms. A fast but expensive form of memory is 
main memory, typically comprised of microchips. ^ 
Other available forms of memory are known as periph- 
eral storage devices and include magnetic direct access 
storage devices (DASD), magnetic tape storage de- 
vices, and optical recording devices. These types of 
memories actually stor data on storage media therein. 35 
Each of these other types of memory has a greater 
storage density and lower cost than main memory. 
However, these other memory devices do not provide 
the performance provided by main memory. For exam- 
ple, the time required to properly position the tape or 
disk beneath the read/write mechanism of the drive 
cannot compare with the rapid, purely electronic data 
transfer rate of main memory. 

It is inefficient to store all of the data in a computer 
system on but a single type of memory device. Storing 45 
all of the data in main memory is too costly and storing 
all of the data on one of the peripheral storage devices 
reduces performance. Thus, a typical computer system 
includes both main memory and one or more types of 
peripheral storage devices arranged in a data storage 50 
hierarchy. The data storage hierarchy arrangement is 
tailored to the performance and cost requirements of 
the user. In such a hierarchy, main memory is often 
referred to as primary data storage, the next level of the 
hierarchy is often to referred to as secondary data stor- 55 
age, and so on. Generally, the highest level of the hier- 
archy has the lowest storage density capability, highest 
performance and highest cost As one proceeds down 
through the hierarchy, storage density generally in- 
creases, performance generally decreases, and cost gen- 60 
erally decreases. By transferring data between different 
levels of the hierarchy as required, the cost of memory 
is minimized and performance is maximized. Data is 
thus stored in main memory only so long as it is ex- 
pected to be required by the processor. The hierarchy 65 
may take many forms, include any number of data stor- 
age or memory levels, and may be able to transfer data 
directly between any two distinct memory levels. The 
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transfer of data may employ I/O channels, controllers, 
or cache memories as is well known in the art 

Images may be included in engineering drawings, 
financial and insurance documents, medical charts and 
5 records, etc. Until recently, it was not possible to store 
image data in memory in a cost effective manner. Im- 
ages can take many forms, and therefore cannot be 
encoded into the binary O's and Vs of computers as 
easily and compactly as text. Engineering drawings are 

10 typically stored on paper, microfilm, or microfiche 
requiring manual retrieval when access to a drawing is 
necessary. The same is true for X-rays and other diag- 
nostic medical images, bank checks used in transactions 
between financial institutions, insurance records, images 

15 in FAX documents and so on. Thus, despite modern 
computers, it is estimated that most of the world's data 
is still stored on paper. The cost of filing, storing, and 
retrieving such paper documents including image data 
is escalating rapidly. It is no longer acceptable to rnain- 

20 tain rooms or warehouses stocked full of documents 
- which must be retrieved manually when access thereto 
is required. Optical scanners are now capable of con- 
verting images into machine readable form for storage 
on peripheral storage devices, but the storage space 

25 required for the image data— although significantly less 
than that required for paper documents — is still quite 
large. Numerous disks or tapes are required for most 
business applications. Automated storage libraries have 
thus been developed to manage the storage of such disks 

30 or tapes. 

Automated storage libraries include a plurality of 
storage cells or slots for retaining data storage media, 
such as magnetic tapes, magnetic disks, or optical disks, 
a robotic picker mechanism, and one or more internal 

35 peripheral storage devices. Each data storage medium 
may be contained in a cassette or cartridge housing for 
easier handling by the picker. The picker operates on 
command to transfer the data storage media between 
the storage cells and the internal peripheral storage 

40 devices without manual assistance. An internal periph- 
eral storage device having a storage medium mounted 
therein is referred to as "occupied". Once a data storage 
medium is mounted in an internal peripheral storage 
device, data may be written to or read out from that 

45 s medium for as long as the system so requires. Data is 
stored on a medium in the form of one or more files, 
each file being a logical data set A file is considered 
"open" when it is reserved for access by a particular 
user and the storage medium upon which it resides is 

50 mounted in a peripheral storage device and ready to be 
accessed. For example, in an optical disk library, a file is 
open if it is reserved for exclusive access and the disk on 
which it resides is mounted in a drive and spinning. A 
peripheral storage device having a storage medium 

55 therein with an omen file is referred to as "active**, 
regardless of whether actual electronic transfer is oc- 
curring. A peripheral storage device is also active if the 
storage medium mounted therein is undergoing access 
under any standard operating system command not 

60 requiring that a file be open, such as a directory read. 
An active storage medium is generally considered to be 
one in an active peripheral storage device. The interna! 
peripheral storage devices and storage cells may be 
considered distinct levels of a data storage hierarchy. In 

«5 addition* data storage media in shelf storage (i.e. not in 
the storage cells, but instead outside the reach of the 
robotic picker without manual intervention) may be 
considered yet another level of a data storage hierarchy. 
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Automated storage libraries may also include one or 
more external peripheral storage devices. An external 
peripheral storage device is a peripheral storage device 
which, unlike internal peripheral storage devices, is not 
accessible by the picker but must instead be loaded and 5 
unloaded manually. External peripheral storage devices 
may be included in libraries as a convenience to the 
library operator. A shelf storage medium requiring brief 
access will not have to be inserted into the library and 
retrieved by the picker for mounting in one of the inter- 10 
nal peripheral storage devices. External peripheral stor- 
age devices may also be a considered a distinct level of 
a data storage hierarchy. Except as explicitly mentioned 
herein, "peripheral storage devices" hereinafter refers 
to internal peripheral storage devices only. 15 

Several automated storage libraries are known. IBM 
Corporation introduced the 3850 Mass Storage Subsys- 
tem for the storage and retrieval of magnetic tape mod- 
ules in the 1970's. More recently, several firms have 
introduced automated storage libraries for magnetic 20 
tape cartridges and optical disks. For example, mag- 
netic tape cartridge libraries are disclosed in U.S. Pat. 
Nos. 4,654,727 and 4,864,438, and 4,864,511. Examples 
of optical disk libraries can be found in U.S. Pat. Nos. 
4,271,489, 4,527,262, 4,614,474, and 4,766,581. The ro- 25 
botic picker mechanisms of these libraries include one 
or more grippers, each gripper capable of handling one 
data storage medium at a time. The *489, *262, *474 
patents disclose robotic pickers having but a single 
gripper and the '727, *438, *51 1, and '581 patents disclose 30 
robotic pickers having multiple grippers. IBM also mar- 
kets the 9246 Optical Library Unit which is a two grip- 
per library. 

Normally, peripheral storage devices and automated 
storage libraries interface differently with the data pro- 35 
cessing systems to which they attach. For a single pe- 
ripheral storage device, such as a disk drive, accessing a 
file only requires the specification of that peripheral 
storage device and the name of the file. For an auto- 
mated storage library, two basic interfaces are known. 40 
In most libraries, the data storage medium or data vol- 
ume including the designated file, the location of such 
data storage medium within the library, and the periph- 
eral storage device through which the data storage 
medium is to be accessed must be specified. The re- 45 
quester must therefore manage the contents of the li- 
brary to maintain an awareness of the information re- 
quired to access a file. In the second interface, imple- 
mented in the 3850 Mass Storage Subsystem, accessing 
a file initially requires the designation of the data stor- 50 
age medium or data volume including the file only. The 
library locates the file therein, mounts the data storage 
medium including the file (If necessary), and informs the 
requester of the peripheral storage device in which the 
medium has been mounted. Actual access is then made 55 
directly between the peripheral storage device in which 
the medium is mounted and the requester— the re- 
quester must specify such peripheral storage device to 
read and write data. Again, the requester must at least 
understand that it is communicating with a library. 60 
Thus, in either type of interface, the requester (a host 
processor or an application running thereon) must have 
some knowledge of library management to be able to 
properly interface with it 

Having established that libraries are to some extent 65 
explicitly managed by a requester to which they attach, 
the software for the data processing system including 
the library and die requester must be adapted to issue 
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the requisite commands and specify the aforementioned 
information for utilizing the library. The requester must 
therefore be able to determine the information required 
to be specified, such as the data storage medium includ- 

5 ing the designated file. In addition, when an automated 
storage library is added to an existing data processing 
system, the system software must be modified to permit 
specification of the information which the library re- 
quires to make a file of data accessible to a user. A 

10 standard file access method for a single peripheral stor- 
age device cannot be used. Such modification to the file 
access method is costly and slows the addition of an 
automated storage library to a data processing system. 

5 SUMMARY OF THE INVENTION 

In view of the foregoing, it is the principal object of 
this invention to provide an improved automated stor- 
age library, and a program product and path format 
therefor. 

20 Another object of this invention is to provide an 
automated storage library which appears to a system 
essentially as does any single peripheral storage device, 
and a program product and path format therefor. 
Still another object of this invention is to provide for 

25 management of an automated storage library by a re- 
quester without requiring additional complexity of such 
requester to allow it to specify the certain information 
for accessing the desired data, and an automated storage 
library and program product therefor. 

30 These and other objects of this invention are accom- 
plished by an automated storage library which masks its 
contents from a requester. The automated storage li- 
brary provides for all of its own internal management. 
To access a file in the library, a requester need only 

35 specify the volume and file on which the file resides. 
The library will locate the volume therein, mount such 
volume (if necessary) in any available peripheral stor- 
age device, and permit continued access to the data on 
such volume without any specification of such device. 

40 A standard file access method for a single peripheral 
storage device may thus be used by the requester —re- 
quiring no modification to the requester when the li- 
brary is attached thereto. 
The path format is the same as that for a single, pe- 

45 ripheral storage device except that the peripheral stor- 
age device designator is replaced with a designator for 
the automated storage library and a volume label is 
inserted as a path element When a host processor re- 
quires access to a file of data it need only specify the 

50 designator for the automated storage library, the vol- 
ume label for the volume in which the file of data re- 
sides, the subdirectory path on the volume, and the 
filename in its request for access. The volume label is 
specified as a path element as if it is a subdirectory. The 

55 automated storage library is capable of extracting the 
volume label from the request, locating the required 
volume using its own internal data structures, and allo- 
cating a peripheral storage device therein upon which 
to mount the volume for the access. Because the desig- 

60 nator for the automated storage library is analogous to 
a designator for a single, peripheral storage device, and 
because the volume label appears as a subdirectory to 
the host processor, management of the automated stor- 
age library is transparent to the host processor— the 

65 automated storage library appears as does any single, 
peripheral storage device to the host processor. A pro- 
gram product for use with the library and the path 
format is also disclosed 
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The foregoing and other objects, features, and advan- 
tages, of the invention will be apparent from the follow- 
ing more particular description of the preferred embodi- 
ment of the invention, as illustrated in the accompany- 
ing drawing. 5 

BRIEF DESCRIPTION OF THE DRAWING 

FIG. 1 is a front, perspective cut-away view of an 
automated optical disk library of the present invention. 

FIG. 2 is the same view as in FIG. 1 except that the 
console panel has been swung aside and the fan has been 
removed. 

FIG. 3 is a rear, perspective cut-away view of the 
automated optical disk library of FIGS, 1 and 2. 

FIG. 4 is a magnified view of the robotic picker and 
gripper of FIG. 3. 

FIG. 5 is a schematic diagram of the optical disk 
library hardware of FIGS. 1-4* 

FIG. 6 is a schematic block diagram of the system 
controller of the optical disk library of FIGS. 1-5. 

FIG. 7 is a sample path specification for a file in the 
optical disk library of FIGS. 1-5. 

FIG. 8 is a schematic block diagram of the internal 
data structures created during initialization. 

FIG. 9 is a flow chart of the operations of the system 
controller of an optical disk library in translating a net- 
work request received at its upper interface into SCSI 
command packets at its lower interface according to the 
present invention. 

FIG. 10 is a flow chart of the high level operations of 
FIG. 9 for a representative IFS entry point 

FIG. 11 is a flow chart of the PARSE routine called 
in FIG. 10. 

FIG. 12 is a flow chart of the READY VOLUME 
routine called in FIG. 10. 

FIG. 13 is a flow chart of the IN CELL routine 
called in FIG. 12. 

FIG. 14 is a flow chart of the IN DRIVE routine 
called in FIG. 12. 

FIG, 15 is a flow chart of the SWAP routine called in 
FIG. 12. 

FIG. 16 is a flow chart of the ALLOCATE routine 
called in the aforementioned routines. 

FIG. 17 is a flow chart of the FORCE ALLOCATE 
routine called in the aforementioned routines. 

FIG. IS is a flow chart of the RELEASE VOLUME 
routine called in FIG. 10. 

FIG. 19 is a flow chart of the IDLE DEMOUNT 
routine according to one embodiment of the present 
invention. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

Referring now more particularly to the drawing, like 
numerals denote like features and structural elements in SS 
the various figures. The automated storage library of 
the invention will be described as embodied in an opti- 
cal disk library. Referring to FIGS. 1-4, various views 
of such an optical disk library is shown. The library 1 
includes a housing 2 enclosing most of the working 60 
parts of the library and having front and rear door pan- 
els (not shown) for interior access. library 1 further 
includes a plurality of optical disk storage cells 3 and a 
plurality of internal optical disk drives 4. Each storage 
cell 3 is capable of storing one optical disk having data 65 
recorded on one or both sides thereof. The data stored 
on each side of a disk is referred to as a M volume**. In the 
preferred embodiment, library 1 includes 144 storage 
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cells 3 arranged in two 72 storage cell columns and up 
to four optical disk drives 4. The optical disks may 
include ablative, phase-change, magneto-optic, or any 
other optical recording layers and may be read-only, 

5 write-once, or rewritable, as is known, so long as they 
are compatible with optical disk drives 4. In addition, 
the optical disks may be recorded in a spiral or concen- 
tric track pattern. The precise recording format is not 
part of the subject invention and may be any known in 

10 the art A robotic picker 5 includes a single gripper 6 
capable of accessing an optical disk in any of storage 
cells 3 or drives 4 and transferring such optical disks 
therebetween. In the preferred embodiment, the optical 
disks are configured in cartridges for easy handling by 

15 gripper 6 and are 5 and \ inch form factor disks, but in 
alternative embodiments could be any size compatible 
with drives 4 and gripper 6. 

Although the front face of housing 2 is not shown in 
FIG. 1, certain portions of library 1 protrude through 

20 such front face of housing 2 for operator access. These 
portions are part of a console door 7 and include all or 
part of a power indicator/switch 8, an entry/exit slot 9, 
an external optical disk drive 10, a console 11, and a 
keyboard 12. Console door 7 can be swung aside to 

25 allow access therebehind, when necessary, as shown in 
FIG. 2. Slot 9 is used for inserting optical disks to or 
removing optical disks from library 1. Commands may 
be provided by an operator to library 1, via keyboard 
12, to have picker 5 receive an optical disk inserted at 

30 slot 9 and transport such disk to a storage cell 3 or drive 
4, or to have picker 5 retrieve an optical disk from a 
storage cell 3 or drive 4 and deliver such disk to slot 9 
for removal from library 1. Console 11 allows an opera- 
tor to monitor and control certain operations of library 

35 1 without seeing inside housing 2. External optical disk 
drive 10, unlike drives 4, cannot be accessed by gripper 
6. Drive 10 must instead be loaded and unloaded manu- 
ally. Library 1 also includes an optical disk drive ex- 
haust fan 14, an external disk drive exhaust fan 15, and 

40 power supplies 16. 

Once library 1 is powered on, commands received at 
keyboard 12 are forwarded to a system controller 17. In 
the preferred embodiment, system controller 17 is an 
IBM PS/2 Model 80 personal computer using the OS/2 

45 operating system. The IBM PS/2 model 80 personal 
computer includes main memory and one or more stor- 
age media, such as those in fixed or floppy disk drives. 
System controller 17 issues instructions to drives 4, 
external drive 10, and picker 5 as will be described. 

50 Drive controller cards 13 and picker 5 controller card 
18 convert known small computer system interface 
(SCSI) command packets issued by system controller 17 
into the electromechanical action of drives 4, external 
drive 10, and picker 5. The movement of picker 5 within 

55 library 1 is X-Y in nature. Movement in the vertical 
direction is driven by a vertical direction motor 19 and 
movement in the horizontal direction is driven by a 
horizontal direction motor 20. Motor 19 turns a lead 
screw 21 to move picker 5 vertically. Motor 20 turns 

60 belts 22 and 23 to move picker 5 horizontally. In addi- 
tion, picker S may be rotated to bring either side of an 
optical disk within the grasp of gripper 6 to an upright 
position. The remaining physical features of library 1 
are not shown in the drawing, or are shown but not 

65 labeled for the purpose of simplification, but are well 
known. 

Referring to FIG. 5, the system connections of li- 
brary 1 will now be described. System controller 17 is 
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attached to one or more host/system processors 30 to 
receive input therefrom and to transmit output thereto. 
System processor 36 can be a host central processing 
unit (CPU), such as an IBM 3090 mainframe processor 
using the MVS or VM operating system or IBM 5 
AS/400 xnidrange computer using the OS/400 or AIX 
operating system, or a network of processors, such as 
IBM PS/2 personal computers using the OS/2 or DOS 
operating system and arranged in a local area network 
(LAN). The connections to system processor 30 are not 10 
shown, but are well known. If system processor 30 is an 
IBM 3090 mainframe processor, the connection could 
be made using an IBM System/370 channel attachment 
according to the interface described in IBM Document 
#SA22-7091-00, "IBM Channei-to-Channel Adapter", 15 
June, 1983, IBM Document #GA22-6974-09, "IBM 
System/360 and System 370 I/O Interface Channel to 
Control Unit Original Equipment Manufacturers Infor- 
mation", February, 1988, and IBM Document #SA22- 
7085-01, "IBM System/370 Extended Architecture 20 
Principles of Operation", January, 1987, each of which 
are hereby incorporated by reference. If system proces- 
sor 30 is an IBM AS/400 midrange computer, the con- 
nection could be made using a direct, SCSI interface 
attachment wherein library 1 is directly controlled by 25 
the host system according to ANSI standard 
X3T9.2/86-109 rev. 5, hereby incorporated by refer- 
ence. If system processor 30 is a plurality of IBM PS/2 
personal computers arranged in a LAN, the connection 
could be made using the NETBIOS control program 30 
interface of the IBM Token Ring Network LAN at- 
tachment, according to the protocols described in IBM 
Document #SC2 1-9526, "Distributed Data Manage- 
ment Level 2.0 Architecture Reference", March, 1989, 
hereby incorporated by reference. The preferred em- 35 
bodiment of library 1 will hereinafter be described as 
used as a file server in a LAN environment wherein 
library 1 appears to the system as a shared, general 
storage device- 
System controller 17 is attached to drives 4, picker 5, 40 
and external optical disk drive 10 via known single- 
ended SCSI connections, including SCSI bus 31. In an 
alternative embodiment, system controller 17 may be 
similarly connected to another physical box to direct 
the operations of such other box, not shown in the 45 
drawing. The other box would be essentially identical 
to that shown in FIGS. 1-4, except that the other box 
would not physically include a system controller 
therein, but would instead be controlled by system con- 
troller 17 via SCSI bus 32. The logical subsystem in- 50 
eluding both physical boxes, one box with a system 
controller and one box without a system controller, is 
considered to be a single library. In addition, for use in 
certain environments, two system controllers can be 
connected via an RS-232 interface (not shown) to create 55 
a library including two boxes with system controllers 
and two boxes without system controllers, and so oil 
Referring to FIG. 6, a functional component level 
description of system controller 17 will now be pro- 
. vided. Generally, system controller 17 is designed to 60 
support major library functions such as creating and 
deleting files, writing to and reading from the files, 
moving optical disks between storage cells 3, drives 4, 
and slot 9, and providing statistics on usage and errors. 
Volumes in the library appear as subdirectories in the 65 
root directory of a single drive. Labels assigned to each 
volume represent the subdirectory name. System pro- 
cessor 30 is able to read the root directory, but cannot 
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store files in the root directory. Any paths accessed on 
a volume appear as paths under the subdirectory ele- 
ment that represents the volume label. 
Standard path protocol known in the personal com- 

5 puter environment is used to access files in library 1. 
The path format is shown in FIG. 7 and includes path 
elements 35-37 and 39. Of the path elements, **d: w is the 
designator 35 for library 1, "volid" is the volume label 
36, **pathl/path2" etc. is the normal subdirectory path 

10 specification 37, and "fiicext" is the filename and exten- 
sion 39. Backslashes are used to separate path elements. 
Designator 35 for library 1 is a letter and colon as is 
used for any peripheral storage device in the personal 
computer environment, such as the commonly used 

15 **c:" for a fixed disk drive. Volume label 36 appears as a 
subdirectory element in the root directory of the desig- 
nated hardware. Because the first apparent subdirectory 
element is actually the volume identifier and the remain- 
ing subdirectory elements are the actual path 37, library 

20 1 appears to system processor 30 as does any single, 
peripheral storage device. Library 1 requires no instruc- 
tion as to the physical location of the volume within 
library 1, the drive 4 in which to mount the volume, etc. 
Instead, system controller 17 makes all such determina- 

25 tions and directs the appropriate actions. Library man- 
agement is thus transparent to users. 

A generic library file server (GLFS) 50 controls the 
library with a set of generic, intermediate hardware 
commands through a formally defined interface which 

30 will be described later herein. Data is manipulated by 
GLFS 50 at the logical record level allowing for data 
access in quantities spanning from a single byte to com- 
plete, variable length data objects. An operating system 
51 mediates the flow of control and directs incoming 

35 operating system co,hands from the external interfaces 
into the library subsystem. Operating system 51 can be 
any of several known operating systems and in the pre- 
ferred embodiment is the OS/2 operating system. The 
use of the OS/2 operating system generally allows for 

40 control of library 1 through standard fixed disk operat- 
ing system commands. Library control is directed 
through a unique command, DosFsCtl. This command 
is used to support initialization, entry/exit of an optical 
disk from library 1, read/store the library map file, 

45 mount/demount an optical disk in drive 10, enable/disa- 
ble virtual drive option, etc. Drive control is directed 
through a unique command, DosDevIOCtl. The re- 
mainder of the programmed control for library 1 is 
retained in microcode which is uploaded into the main 

50 memory of system controller 17 from a storage medium 
resident therein at initialization. In alternative embodi- 
ments, some function required to support the micropro- 
grammed control may also be provided as a utility to 
the operating system running in system processor 30. 

55 The OS/2 operating system includes several ad- 
vanced operating system concepts integral to system 
controller 17. These advanced concepts are dynamic 
link libraries, installable file systems, and multitasking. 
A dynamic link library (DLL) is a file containing a set 

60 of functions each of which may be dynamically loaded 
as needed. Normally, a program is compiled and linked 
with the compiled program code of all of the functions 
the program might invoke before it can be executed. A 
DLL permits a program to invoke functions compiled 

65 and linked into independent modules of program code. 
OS/2 includes a set of DLL modules that can be in- 
voked as required. Using a custom DLL module, OS/2 
can be made to control non-standard storage devices. 
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The custom DLL module is known as an installable file 
system (IFS). Each function supported by an IFS is 
known as an entry point For additional information on 
installable file systems, see IBM Document #G362- 
0001-03, "IBM Personal Systems Developer", Fall, 5 
1989, hereby incorporated by reference- In the pre- 
ferred embodiment, GLFS 50 is implemented as an IFS 
to the OS/2 operating system with prescribed entry 
points- 

Another important aspect of the OS/2 operating 10 
system is multitasking. Multitasking is the ability of a 
system to run multiple programs concurrently. The 
system processor's time is apportioned amongst tasks 
each appearing to be running as if no other tasks are 
present. A separate environment is maintained for each 15 
task; memory and register contents for each task are 
isolated to avoid interference with each other. A task 
and its associated environment is referred to as a 
"thread". Programs can include a code area and a data 
area in the main memory of the IBM PS/2 model 80 20 
personal computer. The code area is the section of 
memory containing the instructions being executed for 
any given thread. The data area is the section of mem- 
ory (or registers) that is manipulated during execution 
of the instructions. Because the same code area may be 25 
used for several threads, each thread may point to the 
same code area for execution but includes its own iso- 
lated data area. 

The upper interface translator 80 is responsible for 
translating between upper interface commands and 30 
those of GLFS 50. The lower interface translator 90 is 
responsible for translating between the commands is- 
sued by GLFS 50 and those of the lower interface. 
Translators 80 and 90 are each implemented as distinct 
linkable modules with clearly defined interfaces, 35 
thereby permitting easy attachment of library 1 to new 
upper and lower interfaces. The only G impact of at- 
tachment to a new interface is the creation of a new 
portion of translators 80 and 90— the generic nature of 
GLFS 50 allows it to remain unchanged. 40 

The upper interfaces of library 1 include the library 
configuration, map, and system performance files, con- 
sole 11 (and keyboard 12), and the network interface. 
The library configuration, library map, and system per- 
formance files are not shown in the drawing, but are 45 
stored on the fixed disk drive of system controller 17. 
These files are maintained by the library operator. The 
library configuration file lists various characteristics of 
the hardware configuration of library 1, such as the 
number of physical boxes in library 1, the number of 50 
drives 4 and 10 in each physical box, whether a drive is 
an internal drive 4 or an external drive 10, the number 
of storage cells 3 in each physical box, the SCSI ad- 
dresses of each picker 5 and drive 4 or drive 10, etc. The 
library map file lists various characteristics of the opti- 55 
cal disks in library 1, such as the volume label of each 
optical disk in library 1, the address of the home storage 
cell for each optical disk in library 1, tree space informa- 
tion for each optical disk, and certain usage statistics for 
each optical disk, such as the number of mounts, the 60 
date and time of last access, eta System controller 17 . 
uses the library configuration and map files to identify 
the number and arrangement of resources in the library, • 
and adjusts the files as the status of the resources in 
library 1 changes. The system performance file lists 65 
operator specified parameters such as the virtual dri ve 
option parameter U, minimum virtual drive eligibility 
time V, minimum demount eligibility time W, preemp- 
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tive demount eligibility time X, and idle demount time 
Y, all of which are defined later herein- Console 11 is 
used to exhibit the ongoing status of the library compo- 
nents and make commands and utility functions, such as 

5 error reporting, available to the operator. Keyboard 12 
allows the operator to make manual input to library 1, 
such as in response to information received via console 
11. Console 11 and keyboard 12 are linked to GLFS 50 
by console driver 81 and console logical manager 83. 

10 The network is linked to LAN adapter driver 82 and 
NETBIOS network control program 84. The network 
interface allows a processor on the network to remotely 
gain access to library 1, which acts as a file server 
thereto. 

15 GLFS request manager 52 is the interface to operat- 
ing system 51 and responds to the same set of entry 
points that the OS/2 operating system uses to communi- 
cate with any IFS. GLFS request manager 52 is respon- 
sible for breaking down operating system commands to 
20 accomplish library functions, which it does by calling 
routines found in the process control manager (PCM) 
53a to accomplish each step. PCM 53a is a set of utility 
routines, some of which require the generation of re- 
quest blocks, that assist the system in breaking down 
25 and processing commands. The routines parse directory 
path strings, enter optical disks into the library, locate 
volumes, allocate drives to a volume, flip optical disks 
so as to present the volume on the opposite side for 
mounting, mount volumes, demount volumes, exit opti- 
cal disks from the library etc. and will be described 
further where appropriate. The directory management 
scheme (DMS) 53b is a module of code which satisfies 
the IFS file specification for monitoring the open/- 
35 closed status of the user files in library 1, as is well 
known, and is used to manipulate such user files. Use of 
the IFS interface in such an internal module allows for 
easy adaptation of external IFS-style implementations 
of directory management schemes. 
4Q The power on initialization (POI) module 54 manages 
the power on and reset functions of the controller and is 
invoked by operating system 51 at initialization. POI 
module 54 is responsible for functions such as determin- 
ing and reporting the results of component self-testing 
45 and reading the library configuration and status files. 
Errors are processed by an error recovery module 56 
and an error logging module 57. Recovery module 56 
processes all errors, including dynamic device realloca- 
tion and retries of device commands. Logging module 
50 57 is responsible for saving error information and re- 
porting it to the operator via console 11. 

The resource manager 60 dynamically allocates and 
deallocates control blocks in the data area of system 
controller 17, including request blocks, drive control 
55 blocks, and error information blocks. Request blocks 
are used to request a hardware event for drives 4 or 
picker 5* Drive control blocks are used to store status 
information relating to drives 4, as will be described 
later herein* Error information blocks are used to store 
60 the information needed to report, isolate, and possibly 
retry an error. The allocation and deallocation of con- 
trol blocks is accomplished using a list of the free space 
« available in the main memory of the IBM PS/2 model 
80 personal computer maintained by resource manager 
65 60, Note that both error recovery module 56 and re- 
source manager 60 are connected to most of the compo- 
nents of system controller 17 shown in FIG. 6, such 
connections not being shown for simplification. 
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The schedulers 61 and 62 are responsible for verify- 
ing the contents of the request blocks and entering them 
into the pipe for the hardware device that will process 
the request. A pipe is a queued data path leading from 
one thread to another and can be accessed by any thread 5 
knowing the assigned identifier of the pipe. The dis- 
patchers 63 and 64 are responsible for validating the 
request blocks, ensuring that the requests are ready to 
be executed, and dispatching the request as appropriate 
to the drive logical manager 91 and the library logical 10 
manager 92. The coordinator 65 is responsible for coor- 
dinating request execution for dispatchers 63 and 64, 
The coordinator accomplishes such using a table having 
an entry for each request block received from PCM 
53a. Each entry lists the supporting request blocks asso- 15 
ciated with a particular request block. A request requir- 
ing the prior completion of another request is referred 
to as "dependent", the request that must first be com- 
pleted is referred to as "supporting". Coordinator 65 
withholds execution of dependent request until associ- 20 
ated supporting requests have been executed. If a sup- 
porting request fails execution coordinator 65 rejects 
requests dependent thereon. 

Logical managers 91 and 92 are responsible for trans- 
lating the generic library commands in the form of 25 
request blocks into the equivalent device level com- 
mands in the form of SCSI data packets. Logical man- 
agers 91 and 92 are also responsible for receiving hard- 
ware status information from the drive driver 93 and the 
library driver 94 respectively. Drivers 93 and 94 di- 30 
rectly manipulate the hardware and physical memory. 
Drivers 93 and 94 perform all communications with 
their respective hardware and also respond to inter- 
rupts. Logical manager 91 and drive driver 93 control 
drives 4, logical manager 92 and library driver 94 con- 35 
trol picker 5. Although not shown in FIG. 6 for simplic- 
ity, there are actually multiple drive dispatchers 63, 
drive logical managers 91, and drive drivers 93 — one set 
for each drive 4 or 10 in library 1. Each set is connected 
to a different data pipe. 40 

METHOD OF OPERATION 

Initialization of library 1 is accomplished using oper- 
ating system 51, GLFS request manager 52, resource 
manager 60, and POI module 54. After self-testing of 45 
the library hardware to verify correct function, operat- 
ing system 51 is loaded and uses the OS/2 CONFIG.- 
SYS file to set the operating system parameters and load 
drivers. Operating system 51 then generates an initial- 
ization command which is passed to GLFS request 50 
manager 52 and then on to POI module 54* POI module 
54 reads the library configuration, map, and system 
performance files, creates the necessary internal data 
structures in the main memory of the IBM PS/2 model 
80 personal computer, and initiates separate threads for 55 
each hardware component of library 1 specified in the 
library configuration file. Resource manager 60 initial- 
izes internal tables used in memory management. POI 
module 54 then queries system controller 17 and con- 
troller cards 13 and 18 for power-on self-test results and 60 
reports any problems to error recovery module 56. Any 
errors detected during initialization are logged by error 
logging module 57 and, if possible, recovered by error 
recovery module 56. When system controller 17 is in a 
ready state, the system is receptive to activity from 65 
console 11 or the network interface. Referring to FIG. 
8, the internal data structures include the optical library 
main system control block (OLMSCB) 110, one or 
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more library control blocks (LCB) 111, fixed drive 
control blocks (DCB) 112, an active DCB pointer array 
113, active DCBs 114, and an optical disk map 115. 
Pointers are represented by arrows in FIG. 8. 

5 OLMSCB 110 includes the number of physical boxes in 
library 1, the virtual drive option parameter U, mini- 
mum virtual drive eligibility time V, a pointer to the 
optical disk map, and a pointer to a LCB 111 for each 
physical box in library 1 (for convenience, only one 

10 such LCB is shown in the drawing). Each LCB 111 
includes for the respective physical box the operational 
status of picker 5 (on-line, off-line, failed), the number of 
drives 4 and 10 therein, the SCSI address of picker 5 
therein, the number of storage cells 3 therein, the ad- 

15 dress of each storage cell 3 and slot 9 therein, the mini- 
mum demount eligibility time W, the preemptive de- 
mount eligibility time X, the idle demount time Y, and 
a pointer to a fixed DCB 112 for each drive 4 or 10 
therein. Each LCB 111 also includes a pointer to active 

20 DCB pointer array 113, which in turn includes a pointer 
to an active DCB 114 for each drive 4 or 10 therein. 

Five fixed DCBs 112 are shown in the drawing, one 
for each drive 4 and drive 10 in the preferred embodi- 
ment. Each fixed DCB 112 includes certain drive spe- 

25 cific information about drives 4 and 10 which is "fixed" 
in that it does not change as optical disks are manipu- 
lated about library 1. Such information includes for the 
respective drive the operational status of the drive in- 
cluding a usage attribute indicating whether use of the 

30 drive is restricted to certain functions (such as write 
only). Fixed DCBs 112 are used as permanent records 
of such information to create active DCBs 114 as opti- 
cal disks are manipulated about library 1, as will be 
described, 

35 Six active DCB pointers 113 and active DCBs 114 are 
shown in the drawing, one for each drive 4 and drive 10 
in the preferred embodiment, and one for the virtual list, 
which is a linked list of the access records for certain 
volumes, as will be described. Active DCBs 114 include 

40 certain volume specific information about drives 4 and 
10 and the virtual accesses. The information is "active*' 
in that it does change (i.e. it is updated) as optical disks 
are manipulated about library 1. Such information in- 
cludes for the respective drive or virtual access the 

45 appropriate information from fixed DCBs 112 and also 
the occupancy status of the drive (whether or not there 
is an optical disk mounted therein), usage statistics such 
as the last access time and user count for a volume 
therein or virtual access, and an index into the optical 

50 disk map for the entry therein which describes the vol- 
ume mounted in the drive or virtual access. The index 
into the optical disk map is used by DMS S3b to locate 
a volume in library 1, as required. The user count is the 
number of current accesses ongoing for a volume, an 

55 access being an open file or any standard operating 
system command not requiring that a file be opened, 
such as a directory read. 

Optical disk map 115 includes an entry for each stor- 
age cell 3 in library 1. An entry for an empty storage 

60 cell 3 is blank. An entry for a full storage cell 3 lists the 
owner of the disk therein, the home storage cell 3 and 
current location of the disk, and for each volume on the 
disk, the volume label, the number of mounts, the avail- 
able free space, and other usage statistics. The afore- 

65 mentioned data structures also include other informa- 
tion required for the operation of library 1, although not 
explicitly described for simplicity, as is known in the 
art 
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Referring to FIG. 9, the operations of system control- 
ler 17 will now be described. When a request is received 
from the network interface, the network control code 
will convert the request into a set of standard OS/2 
operating system commands at step 100. Operating 5 
system 51 will then issue the appropriate operating 
system calls to process the operating system commands 
at step 101, GLFS request manager 52 receives the calls 
and breaks them down into simpler functions. For each 
function, GLFS request manager 52 will call a routine 10 
in PCM 53a and/or DMS 53b and pass the appropriate 
subset of the data required for the routine as parameters 
at step 102. For each routine requiring hardware activ- 
ity, PCM 53a and/or DMS 536 at step 103 calls re- 
source manager 60 to create a hardware level request 15 
block, issues such block to schedulers 61 and 62, and 
informs coordinator 65 of any hardware dependencies 
to allow for the proper sequencing of the requests, PCM 
53a also returns control and status information to GLFS 
request manager 52 as each routine is completed. 20 

After checking the list of free space available in the 
main memory of the IBM PS/2 model 80 personal com- 
puter, resource manager 60 allocates the required mem- 
ory space for the request block. The routines calling 
resource manager 60 provide most of the information 25 
for a control block, resource manager 60 fills in certain 
additional information such as a control block identifier 
and a request block identifier. Drive scheduler 61 and 
library scheduler 62 receive all hardware event requests 
as request block identifiers and forward them to the data 30 
pipes connected to drive dispatcher 63 and library dis- 
patcher 64 respectively. Dispatchers 63 and 64 continu- 
ally check their respective data pipe for the existence of 
a request block identifier. After receiving a request 
block identifier, dispatchers 63 and 64 call coordinator 35 
65 to determine if the request block is ready to be exe- 
cuted. Coordinator 65 checks the table of request block 
dependencies and prevents dispatchers 63 and 64 from 
issuing the request block identifier until all supporting 
request blocks have been completed. When all request 40 
block dependencies have been met, the request block 
identifier is issued to the respective logical manager 91 
or 92. 

At step 104, logical managers 91 and 92 receive the 
request block identifiers, construct the necessary SCSI 45 
hardware command packets to accomplish the requests, 
and issue the packets to drivers 93 and 94. The hard- 
ware then physically performs the requests. As each 
request is completed logical managers 91 and 92 signal 
such completion. Dispatcher 63 or 64 then issues the 50 
identifier of the next request block to the respective 
logical manager 91 or 92. 

Generally, library mount/demount operations will 
continue on an as needed basis as long as there are exist- 
ing requests to mount volumes. When a volume is first 55 
mounted in a drive 4 or 10, an active DCB 114 pertain- 
ing to the access of such volume is created. The active 
DCB is created by copying the drive specific informa- 
tion relating to the drive 4 or 10 in which the volume is 
mounted from the fixed DCB 112 into a block of mem- 60 
ory and adjusting the appropriate pointers. During ac- 
cess to the volume, the volume specific information 
about such access is updated and stored in the active 
DCB 114. If the volume is demounted, the volume 
specific information is deleted from active DCB 114, 65 
except for the occupancy status information, to indicate 
that the respective drive 4 or 10 is again empty. When 
a volume is again mounted in the respective drive 4 or 
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10, the active DCB 114 is again updated as necessary 
with the appropriate volume specific information, and 
so on. 

Volumes are demounted only to free a drive 4 to 
5 service an existing mount request, thereby maintaining 
drives 4 in an occupied state. Such occupancy maxi- 
mizes the amount of data ready for access. When there 
are no pending mount requests, however, drives 4 may 
be preemptively demounted to ensure the existence of 
10 an unoccupied drive 4 to service forthcoming mount 
requests, and to reduce aging of drives 4 during idle 
periods. If all drives 4 are occupied, one drive 4 may be 
emptied, as will be described- In addition, the activities 
of drives 4 are periodically reviewed to determine if the 
15 volumes in any of the occupied drives 4 should be pre- 
emptively demounted because library 1 is relatively 
idle, as will also be described. During normal library 
operations a drive 4 will therefore be empty only after 
the preemptive demount of a volume. The criteria for 
20 selecting volumes for preemptive demount when all 
drives 4 are occupied and there is no pending mount 
request is different from those criteria used during the 
periodic review of the activity of drives 4. 
A drive 4 can physically write to or read from only 
25 one optical disk at any given time. A request to mount 
a volume at a time when there are no unoccupied drives 
4 normally results in the rejection of the request. How- 
ever, when the virtual drive option is enabled by setting 
. the virtual drive option parameter U to one, a request to 
mount a volume when all drives 4 are occupied allows 
for access to more volumes than there are drives 4 by 
temporarily demounting the least recently used volume. 
The temporarily demounted volume is referred to as 
35 "swapped out" and the newly mounted volume is re- 
ferred to as "swapped in". The drive specific informa- 
tion for the drive 4 is deleted from the active DCB 114 
but the volume specific access information for the tem- 
porarily demounted volume is retained therein. The 
4Q active DCB 114 for the temporarily demounted volume 
is then retained in a special form of active DCB 114 
referred to as the virtual list. The virtual list DCBs 
differ from other active DCBs in that they contain 
pointers to each other to create a linked list. The virtual 
45 list permits resumption of the operations on the volume 
by remounting at the next volume mount request or, 
alternatively, caching can be used to continue access 
without remounting* Upon remounting of the volume, 
the appropriate virtual list DCB is deleted from the 
50 linked list and the volume specific information copied 
into the active DCB 114 for the appropriate drive 4 
Because such access information is retained, a volume 
that has been swapped out under the virtual drive op- 
tion is still considered active and under access. Also, 
55 remounting of a volume that has been swapped out can 
occur in any drive 4 so long as the access information is 
provided to the active DCB 114 for the respective 
drive; a volume access is not tied to the original drive 4 
in which the volume is mounted. A volume that has 
60 been swapped out will not logically appear to be in its 
home storage cell 3 as remounting must be distinguished 
from the mounting of a volume that has not been 
swapped out The actual number of drives 4 in the li- 
brary is thus transparent to users. In alternative embodi- 
es ments, additional virtual eligibility option parameters 
can be used to specify only certain volumes as eligible 
for swapping to prevent churn for volumes frequently 
accessed. 
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Referring to the drawing, the high level operations of 
system controller 17 will now be described in further 
detail beginning at a representative IFS entry point into 
GLFS 50 requesting access to a specific, designated 
volume. The description refers to a series of routines of 5 
PCM 53a, The PARSE routine is used to separate vol- 
ume label 36 from the remainder of the path in the 
request. The READY VOLUME routine is used to 
determine the subsequently required operations depend- 
ing upon the location of the designated volume. The IN 10 
CELL, IN DRIVE, and SWAP routines are called 
depending upon the location of the designated volume. 
The IN CELL routine is called if the designated volume 
is in its home storage cell 3, The IN DRIVE routine is 
called if the optical disk including the designated vol- 15 
ume is already mounted in a drive 4. The SWAP routine 
is called if the designated volume is currently active, but 
has been swapped out of a drive 4 according to the 
virtual drive option. 

The ALLOCATE and FORCE ALLOCATE rou- 20 
tines are called by the IN CELL, IN DRIVE, and 
SWAP ROUTINES as needed. The ALLOCATE 
routine is used to reserve an unoccupied drive 4 for the 
mounting of the volume designated in the request. The 
FORCE ALLOCATE routine is used to reserve an 25 
occupied drive 4 for the mounting of the volume desig- 
nated in the request under the virtual drive option (i.e. 
by swapping in). The MOUNT routine simply causes 
picker 5 to retrieve a volume, mount it in a drive 4, and 
spin it up. The DEMOUNT routine simply causes a 30 
mounted optical disk to be spun down, to be demounted 
by picker 5, and transferred to its home storage ceil 3. 
The MOUNT and DEMOUNT routines include updat- 
ing of the internal data structures as required and return 
an error message if they fail to mount or demount a 35 
volume, respectively. The RELEASE VOLUME rou- 
tine is called after the request is processed to determine 
if preemptive demounting of a volume is appropriate 
even though library 1 is not idle. The IDLE DE- 
MOUNT routine periodically reviews the activities of 40 
drives 4 to determine if any optical disks mounted 
therein are sufficiently idle as to be preemptively de- 
mounted to reduce aging of drives 4. 

The following description of the aforementioned 
routines has been simplified wherever possible for con- 45 
venience to eliminate features already described herein 
or known in the art. For example, the information in 
OLMSCB 110, LCB 111, DCBs 112 and 114, and opti- 
cal disk map 115 are not always referenced as their 
location, content, and use have already been described. 50 
Similarly, information deterniined during a routine may 
be passed on to other routines as such other routines are 
called, as required for the routines being called to exe- 
cute. Also, the term "return*' is used to refer to an exit 
from a routine back to the step which called that rou- 55 
tine, including some indication to the calling step of the 
result of the routine. Specific error messages are not 
provided, but are indicative of the cause of the^rror. 
The term "unavailable** is used to refer to a component 
with an off-line, failed, or locked status, thereby pie- 60 
venting its use. A drive is also considered to be unavail- 
able if usage attribute is incompatible with that required 
for a particular request Finally, references to external 
drive 10 or the need to flip an optical disk over to ensure 
mounting of the desired volume have been eliminated 65 
for simplification. 

Referring to FIG. 10, the request to access a desig- 
nated volume is received from operating system 51 by 
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GLFS request manager 52 at step 200, which then di- 
rects steps 201-210 by calling various PCM 53a rou- 
tines. At step 201, the PARSE routine is called to ex- 
tract the volume label therefrom and locate the desig- 

5 nated volume using the optical disk map. Step 202 
branches according to the result of the PARSE routine. 
If the PARSE routine returns an error message (i.e. is 
not successfully completed) such error message is re- 
turned at step 210. If the PARSE routine is successful, 

10 step 203 branches according to the location of the desig- 
nated volume. If the designated volume is not located in 
library 1, such volume cannot be accessed therein. The 
flow therefore skips to step 210 and an error message is 
returned. If the designated volume is located in library 

15 1, the READY VOLUME routine is called at step 204. 
Upon completion of the READY VOLUME routine, 
step 205 branches according to the result of the 
READY VOLUME routine. If the READY VOL- 
UME routine returns an error message (i.e. is not suc- 

20 cessfully completed) such error message is returned at 
step 210. If the READY VOLUME routine is success- 
ful, operations on the designated volume according to 
the request occur at step 207. When such operations 
complete, the RELEASE VOLUME routine is called 

25 at step 208 to determine if preemptive demounting is 
required. When the RELEASE VOLUME routine 
completes, the result is returned at step 210. 

Referring to FIG. 11, the PARSE routine called at 
step 201 begins at step 250. Step 251 branches according 

30 to the validity of the path specified in the request. The 
validity of the specified path is determined by compar- 
ing it to the standard path protocol described earlier. 
For example, an invalid path format would be one in 
which the first path element is longer than that permit- 

35 ted for volume labels. If the path format is invalid, the 
flow skips to step 260 and an error message is returned. 
If the path format is valid, the first path element (i.e. the 
volume label 36) is extracted from the path specification 
and stored at step 252. At step 253, the remaining path 

40 elements are shifted to eliminate the first path element 
from the path specification. The remaining path specifi- 
cation now includes designator 35, subdirectory ele- 
ments 37, and filename and extension 39. Step 254 
branches according to the existence of subdirectory 

45 elements 37 in the remaining path specification. If subdi- 
rectory elements 37 remain, the flow skips to step 257. 
If no subdirectory elements remain, the global indicator 
*•*.**• is appended to the path specification at step 256. 
At step 257, the path specification into DMS 536 and 

50 the optical disk map are used to locate the specified 
volume in library 1. The existence of the global indica- 
tor means that no subdirectories were specified in the 
request; the entire library 1 must be checked to deter- 
mine the location of the specified volume. When the 

55 PARSE routine completes, the result is returned at step 
260. 

Referring to FIG. 12, the READY VOLUME rou- 
tine called at step 204 begins at step 300 and proceeds 
along different paths depending upon the location of the 

60 designated volume. Step 301 branches according to 
whether the designated volume is currently located in 
its home storage cell 3. If the designated volume is 
located in its home storage cell 3, steps 302 and 303 then 
branch according to whether the request is a new access 

65 for the requesting user to the designated volume and 
according to whether picker 5 is available. If the request 
is not a new access, or if picker 5 is unavailable, the flow 
skips to step 320 and an error message is returned. An 
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error message is returned because the designated vol- 
ume should not be in its home storage cell 3. A volume 
that is physically but not logically located in its home 
storage cell 3 (because it is swapped out of a drive 4) 
will result in step 301 branching to step 302. If the 5 
picker 5 is unavailable, an error message is returned at 
step 320 because mounting of the designated volume 
cannot occur. If the request is a new access, and picker 
5 is available, the IN CELL routine is called at step 306 
to attempt to mount the designated volume in a drive 4. 10 
Upon completion of the IN CELL routine, the 
READY VOLUME routine returns at step 320. 

If the designated volume is not located in its home 
storage cell 3 at step 301, the search to locate the cur- 
rent position of such volume continues at step 307. Step 15 
307 branches according to whether the optical disk 
including the designated volume is already in a drive 4. 
If such optical disk is in a drive 4, no mount operations 
are required and the IN DRIVE routine is called at step 
308. Upon completion of the IN DRIVE routine step 20 
309 branches according to whether the request is a new 
access for the requesting user to the designated volume. 
If the request is not a new access, the flow skips to step 
320. If the request is a new access, the user count of the 
designated volume is incremented at step 310 in prepa- 25 
ration for its being mounted. The READY VOLUME 
routine returns at step 320, 

If the optical disk including the designated volume is 
not in a drive 4 at step 307 (the designated volume is 
already known to be in. library 1, but has not been lo- 30 
cated in its home storage cell 3 or a drive 4), it should 
have been swapped out of a drive 4 according to the 
virtual drive option. Steps 312 and 313 branch accord- 
ing to whether the designated volume is located in the 
virtual list and according to the availability of picker 5. 35 
If the designated volume is not located in the virtual list, . 
or if picker 5 is unavailable, an error message is returned 
at step 320. If the designated volume is not located in 
the virtual list, an error message is returned because 
such volume cannot be located. If picker 5 is unavail- 40 
able, an error message is returned because mounting of 
the designated volume cannot occur. If the designated 
volume is located in the virtual list, and if picker 5 is 
available, the SWAP routine is called at step 315. Upon 
completion of the SWAP routine the READY VOL- 45 
UME routine returns at step 320. 

Referring to FIG. 13, the IN CELL routine called at 
step 306 begins at step 400 and proceeds along different 
paths depending upon the existence of an unoccupied 
drive 4 in which to mount the volume. At step 401, the 50 
ALLOCATE routine is called to reserve a drive 4 for 
mounting of the volume designated in the request Step 
402 branches according to the results of the ALLO- 
CATE routine* If an unoccupied drive 4 is located and 
reserved (ie. the ALLOCATE routine succeeded), the 55 
MOUNT routine is called at step 409 to mount the 
designated volume in the reserved drive 4. If an unoccu- 
pied drive 4 is not located and reserved (i.e. an error 
message is returned), step 404 branches according to 
whether the virtual drive option is enabled. If the vir- 60 
tual drive option is not enabled, the flow slaps to step 
410 and the result of the ALLOCATE routine is re- 
turned If the virtual drive option is enabled, the 
FORCE ALLOCATE routine is called at step 406. 
Although no unoccupied drive 4 exists, the virtual drive 65 
option allows for the swapping in of the designated 
volume. At step 407, branching occurs to the result of 
the FORCE ALLOCATE routine. If the FORCE AL- 
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LOCATE routine returns an error message, such result 
is returned at step 410. If the FORCE ALLOCATE 
routine successfully swaps out die designated volume, 
the MOUNT routine is called at step 409. Upon comple- 
5 tion of the MOUNT routine the IN CELL routine 
returns at step 410. 

Referring to FIG. 14, the IN DRIVE routine called 
at step 308 begins at step 420 and proceeds along two 
basic paths depending upon the availability of the drive 
10 4 in which the designated volume is mounted. Step 421 
branches to step 422 if the drive 4 in which the desig- 
nated volume is mounted is unavailable. Step 422 then 
branches according to whether picker 5 is available. If 
picker 5 is unavailable, the flow skips to step 442 and an 
15 error message is returned. An error message is returned 
becausenhe designated volume cannot be accessed in an 
unavailable drive 4 and cannot be transferred to another 
drive 4 as picker 5 is also unavailable. If picker 5 is 
available at step 422, the SWAP routine is called at step 
20 425 to swap the designated volume out of drive 4. Upon 
completion of the SWAP routine, the READY VOL- 
UME routine is called at step 426. Upon completion of 
the READY VOLUME routine, the IN DRIVE rou- 
tine returns at step 442. 
25 If at step 421 the drive 4 in which the designated 
volume is mounted is available, step 433 branches ac- 
cording to whether the designated volume is located in 
the virtual list. If the designated volume is located in the 
virtual list, the flow skips to step 441 to call the SWAP 
30 routine to attempt to swap in the designated volume. 
The swap routine is called because the optical disk 
including the designated volume is in a drive 4, but the 
designated volume is swapped out of such drive 4. If the 
designated volume is not located in the virtual list, 
35 branching occurs at step 434 according to whether the 
request is a new access for the requesting user to the 
designated volume. If the request is not a new access, an 
error message is returned at step 442. If the request is a 
new access, steps 437 and 438 branch according to 
40 whether the virtual drive option is enabled and accord- 
ing to whether the designated volume is active (i.e. has 
a positive user count). If the virtual drive option is not 
enabled and the designated volume is active, an error 
message is returned at step 442. Otherwise, the user 
45 count of the designated volume is incremented at step 
440 and the SWAP routine is called at step 441. Upon 
completion of the SWAP routine, the IN DRIVE rou- 
tine returns at step 442. 
Referring to FIG. 15, the SWAP routine begins at 
50 step 450 and branches at step 452 according to the need 
to allocate a drive. If no drive 4 needs to be allocated, 
the flow continues at step 463. Step 463 branches ac- 
cording whether the request is a new access for the 
requesting user to the designated volume* If the request 
55 is not a new access, the flow skips to step 466. If it is a 
new access, the user count for the designated volume is 
incremented at step 464 before proceeding to step 466. 
If at step 452 a drive 4 needs to be allocated, the ALLO- 
CATE routine is called at step 453. Step 454 branches 
60 according to the results of the allocate routine. If the 
ALLOCATE routine succeeds in locating and reserv- 
ing an unoccupied drive 4, the flow skips to step 466. If 
the ALLOCATE routine returns an error message, step 
457 branches according to the whether the virtual drive 
65 option is enabled. If the virtual drive option is not en- 
abled, the flow skips to step 487 and the result of the 
ALLOCATE routine is returned If the virtual drive 
option is enabled, the FORCE ALLOCATE routine is 



19 

called at step 459. Step 461 then branches according to 
the results of the FORCE ALLOCATE routine. If the 
FORCE ALLOCATE routine returns an error mes- 
sage, the error message is returned at step 487. If the 
FORCE ALLOCATE routine succeeds, the flow con- 5 
tinues at step 466. 

At step 466, branching occurs according to whether 
the designated volume is already mounted in the allo- 
cated drive 4. If the designated volume is already 
mounted in the allocated drive 4, the flow skips to step 10 
481. If the designated volume is not already mounted in 
the allocated drive 4, branching occurs at step 468 de- 
pending upon the occupancy status of such drive 4. If 
such drive 4 is unoccupied, the flow skips to step 474. If 
such drive 4 is occupied, the optical disk therein is de- 15 
mounted by a call to the DEMOUNT routine at step 
469. Step 471 branches according to the results of the 
DEMOUNT routine. If the DEMOUNT routine re- 
turns an error message, the error message is returned at 
step 487. If the DEMOUNT routine succeeds, the flow 20 
continues with a call to the MOUNT routine at step 
474. At step 476, branching occurs according to results 
of the MOUNT routine. If the MOUNT routine returns 
an error message, the error message is returned at step 
487. If the MOUNT routine succeeds in mounting the 25 
designated volume, branching occurs at step 481 ac- 
cording to the activity status of any volume demounted 
from the allocated drive 4 at step 469. If the user count 
of the demounted volume is positive, the volume spe- 
cific information in active DCB 114 for the allocated 30 
drive 4 for such volume is retained by linking it into the 
virtual list at step 482 and the flow continues at step 484. 
If the user count of the demounted volume is not posi- 
tive, the information in active DCB 114 is discarded at 
step 483 and the flow continues at step 484. At step 484, 35 
the volume specific information in the virtual list for the 
designated volume is copied into active DCB 114 for 
the allocated drive 4. At step 486, the information in the 
virtual list for the designated volume is deleted and the 
flow returns at step 487. Note that because active DCBs 40 
114 are updated as required at steps 482-484 and 486, 
such updating otherwise performed during the 
MOUNT and DEMOUNT routines is inhibited at the 
calls to such routines at steps 469 and 474. 

Referring to FIG. 16, the ALLOCATE routine be- 45 
gins at step 500 and branches at step 502 according to 
the existence of an empty, available drive 4 in which to 
mount the designated volume. If there is an empty, 
available drive 4, the user count for the designated 
volume is incremented at step 503 in preparation for its 50 
being mounted in such drive 4 and the flow skips to step 
513. The empty, available drive 4 is at this point re- 
served for such mounting. If there is more than one 
empty, available drive, the first such drive located by 
examining the internal data structures of library 1 is 55 
allocated. In alternative embodiments, the choice 
among multiple empty, available drives could be made 
using any known scheduling technique, such as FIFO, 
LIFO, round robin, or minimum picker travel tech- 
niques. If there is no empty, available drive 4, steps 506 60 
and 507 branch according to the existence of an avail- 
able, inactive drive 4 and whether any such inactive 
drive 4 has been active in the last minimum demount 
eligibility time W. If there is no available, inactive drive 
4, or if such a drive 4is located but has not been inactive 65 
for time W, the flow skips to step 513 and an error 
message is returned. If there is no available, inactive 
drive 4, an error message is returned as there is little 
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benefit to interrupting the activity of one of the drives 4 
to demount the optical disk therein and subsequently 
mount the designated volume. If there is an available, 
inactive drive 4, but no such inactive drive 4 has been 
5 inactive for time W, no optical disk is demounted and an 
error message is returned, thereby preventing churn 
during piecewise active system applications. If there is 
an available, inactive drive 4 that has been inactive for 
time W, the DEMOUNT routine is called to demount 
10 the optical disk therein at step 511. If more than one 
such drive 4 is located, the optical disk in the drive 4 
that has been inactive the longest (i.e. the least recently 
used optical disk) is demounted. At step 512, the user 
count for the designated volume is incremented in prep- 
15 aration for its being mounted. The ALLOCATE rou- 
tine returns at step 513. 

Minimum demount eligibility time W can be tailored 
to the operating characteristics of the particular library 
and its operating environment. When W is zero, step 
20 507 will always branch to step 511 for demounting. The 
risk is that demounting may occur only to have re- 
mounting of the demounted optical disk required 
shortly thereafter. When W is very large, disks may 
never be demounted as is desired. In the preferred em- 
25 bodiment W is set to between 0 and 10 seconds to main- 
tain the proper balance among these factors. 

Referring to FIG. 17, the FORCE ALLOCATE 
routine begins at step 52D and branches according to the 
existence of an available, inactive drive 4 at step 522. If 
30 there is no available, inactive drive 4, the flow skips to 
step 530 and an error message is returned. An error 
message is returned as there is little benefit to interrupt- 
ing the activity of one of the drives 4 to demount the 
optical disk therein and subsequently mount the desig- 
35 nated volume. If there is an available, inactive drive 4, 
steps 524 and 526 branch according to whether any 
inactive drive 4 has been active in the last minimum 
demount eligibility time W seconds or whether any 
inactive drive 4 has been active in the last minimum 
40 virtual drive eligibility time V. If no inactive drive 4 has 
been inactive for the time W and the time V, an error 
message is returned at step 530. An error message is 
returned because the risk of churn is considered too 
high to demount an optical disk. If there is a drive 4 
45 which has not been active within time W and time V, 
the user count for the designated volume 4 is incre- 
mented at step 528 in preparation for its being mounted. 
At step 529, the SWAP routine is called. Upon comple- 
tion of the SWAP routine, the FORCE ALLOCATE 
50 routine returns at step 530. 

Minimum virtual drive eligibility time V can be tai- 
lored to the operating characteristics of the particular 
library and its operating environment When V is zero, 
step 526 will always branch to steps 528 and 529 to call 
55 the SWAP routine to attempt to demount an optical 
disk under the virtual drive option. The risk is that 
demounting may occur only to have remounting of the 
demounted optical disk required shortly thereafter. 
When V is very large, step 526 will always branch to 
60 step 530, thereby returning the FORCE ALLOCATE 
routine. Such a large value of V effectively diminates 
the FORCE ALLOCATE routine. In the preferred 
embodiment V is set to between 0 and 30 seconds to 
maintain the proper balance among these factors. 
65 Referring to FIG. 18, the RELEASE VOLUME 
routine called at step 208 begins at step 350. Step 351 
branches according to the activity of the drive 4 in 
which the designated volume has been mounted. If the 
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drive 4 is active, the flow skids to step 358. If the drive 
4 is inactive, the user count for the drive 4 is decre- 
mented at step 352 to reflect the inactivity. Step 353 
then branches according to whether the designated 
volume is actually mounted in a drive 4 or is swapped 5 
out under the virtual drive option. If the designated 
volume is actually mounted in a drive 4, the flow skips 
to step 358. If the designated volume is swapped out 
under the virtual drive option, branching occurs at step 
354 according to the activity status of the designated 10 
volume. If the user count of the designated volume is 
positive, the flow skips to step 358. If the user count of 
the designated volume is zero, the access information in 
the virtual list is no longer required and is discarded at ^ 
step 356 before proceeding to step 358. 

Steps 358-364 determine whether any optical disks in 
library 1 should be preemptively demounted. Branching 
occurs at step 358 according to the existence of an avail- 
able, unoccupied drive 4 in library 1. If there is an avail- ^ 
able, unoccupied drive 4, the flow skips to step 365 and 
the RELEASE VOLUME routine returns. Demount- 
ing is not required as an unoccupied drive 4 already 
exists to service a future mount request If all drives 4 
are occupied, the index into the optical disk map for the 2$ 
least recently used volume mounted in an available 
drive 4 is retrieved at step 361. Branching then occurs at 
step 362 according to whether such least recently used 
volume has been active within the last preemptive de- 
mount eligibility time X. If such volume has been active 30 
in the last rime X, demounting is not performed as the 
risk of churn is considered to be too great and the flow 
skips to step 365. If such volume has not been active in 
the last time X, the DEMOUNT routine is called to 
demount the optical disk including such volume at step 35 
364 before proceeding to step 365. Because accessing 
data is often associated with accessing data stored 
nearby, the least recently used volume is considered to 
be the mounted volume least likely to be accessed next 
(i.e. the mounted volume least likely to result in churn if 40 
demounted). Demounting ensures that an empty drive 4 
is available to service the next mount request Note that 
the existence of a pending mount request has no rele- 
vancy to steps 358-364. Even when no mount request is 
pending an optical disk can be demounted (i.e. "preemp- 45 
tively" demounted) in anticipation of a future mount 
request. In alternative embodiments, more than one 
drive 4 may be emptied when all drives 4 are occupied, 
but such is not preferred as it unduly reduces the num- 
ber of optical disks remaining on-line (i.e. mounted and 50 
spinning). Upon completion, the RELEASE VOL- 
UME routine returns at step 365. 

Preemptive demount eligibility time X can be tailored 
to the operating characteristics of the particular library 
and its operating environment When X is zero, step 362 55 
will always branch to step 364 for preemptive demount- 
ing. The risk is that demounting may occur only to have 
remounting of the demounted disk required shortly 
thereafter. When X is very large, disks may never be 
preemptively demounted as is desired. To prevent the 60 
demounting at step 511 of most disks otherwise eligible 
for preemptive demounting at step 364, X should be 
greater than or equal to W. In the preferred embodi- 
ment X is set between 0 and 20 seconds to maintain the 
proper balance among these factors. Where X is less 65 
than W, step 362 should branch according to whether 
the least recently used volume has been active within W 
and X. Branching to step 364 should only occur if the 
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least recently used volume has not been active in the last 
time W and the last time X. 

Referring to FIG. 19, the periodic review of the ac- 
tivities of drives 4 to determine if the optical disk in any 
5 of occupied drives 4 is sufficiently idle as to be preemp- 
tively demounted begins with the periodic interruption 
of console 11 at step 600. In the preferred embodiment 
console 11 interrupted every 10 seconds. The interrupts 
are issued without regard to the status of library 1 with 
10 respect to FIGS. 8-15. At step 601, branching occurs 
according to the activity status of drives 4 as in step 362, 
except that the preemptive demount eligibility time X is 
replaced with a relatively much larger idle demount 
time Y. If no drive 4 has been inactive for time Y, the 
15 flow returns at step 605. Note that because the time Y is 
much greater than the time X, the determination not to 
preemptively demount at step 601 has little, if anything, 
to do with the risk of churn. 
If at step 601 any drive has been inactive for time Y, 
20 the DEMOUNT routine is called at step 602 to preemp- 
tively demount all optical disks mounted in any such 
inactive drive before proceeding to step 605. The exis- 
tence of a drive 4 that has been inactive for time Y is 
considered to be an indication that library 1 is relatively 
25 idle. Idle periods may occur during periods of low over- 
all system use, such as nights and weekends in some data 
processing systems. At such times, it is not desirable to 
continue to spin the optical disks in drives 4. So long as 
disks are spinning, the lasers in drives 4 will continue to 
30 follow the tracks on the disks, resulting in needless 
servo action. The drive motors and lasers will work to 
maintain drives 4 in a state of readiness even though no 
useful work is being performed, thereby prematurely 
aging drives 4. Note that preemptive demounting here 
35 applies to all optical disks mounted in such inactive 
drives, not just the least recently used disk, as the need 
to reduce aging of the drives is considered to outweigh 
the need to maintain disks on-line when library 1 is 
relatively idle. Thus, by preemptively demounting cer- 
40 tain disks during relatively idle periods, the reliability of 
library 1 is improved. In an alternative embodiment, the 
reliability of library 1 could be improved by spinning 
down such disk without their being demounted and 
returned to their home storage cell 3. 
45 Idle demount time Y can be tailored to the operating 
characteristics of library 1 and its operating environ- 
ment When Y is zero, the optical disk in any inactive 
drive 4 will be preemptively demounted from such 
drive 4. The risk is that preemptive demounting of sev- 
50 era! disks may occur just before the activity in library 1 
increases. When Y is very large, disks may never be 
preemptively demounted. Such a large value of Y effec- 
tively dmiinates the IDLE DEMOUNT routine* In the 
preferred embodiment, Y is set between 10 and 30 min- 
55 utes to maintain the proper balance among these factors. 
In an alternative embodiment, no drive 4 is preemp- 
tively demounted unless one or more drives 4 are unoc- 
cupied and one or more of the mounted drives 4 has 
been inactive for time Y. The existence of an unoccu- 
60 pied drive 4 would result from preemptive demount 
operations at steps 358-364. The addition of the need 
for an unoccupied drive 4 to qualify library 1 as rela- 
tively idle reduces the likelihood that demounting 
under the IDLE DEMOUNT routine will occur just 
65 before the activity in library 1 increases. 

In an alternative embodiment, library 1 can be set to 
operate is "fixed" mode or "adaptive" mode, as desig- 
nated in the system performance file and OLMSCB 110. 
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In fixed mode, library 1 operates as previously de- 
scribed. In adaptive mode, the operator specifies times 
W, X, and Y and adaptive mode time Z. Z is a predeter- 
mined time for comparison with the time since an opti- 
cal disk was last demounted. At mounting, if the time 5 
since a disk was last mounted is less than Z, the re- 
mounted disk is considered to be a relatively active disk 
which cannot be preemptively demounted according to 
steps 358-364. Demounting of such a disk only occurs 
as part of the ALLOCATE routine to service a pending 10 
mount request, or as part of the IDLE DEMOUNT 
routine. At mounting, if the time since a disk was last 
mounted is greater than Z, the remounted disk is consid- 
ered eligible for preemptive demounting according to 
steps 358-364. In adaptive mode a disk can have its }5 
eligibility for preemptive demounting adjusted as the 
demand for access to such disk varies over time. The 
more active disks are dynamically sorted from the less 
active disks, thereby further decreasing the likelihood 
of churn. 20 

Adaptive mode time Z can be tailored to the operat- 
ing characteristics of the particular system. When Z is 
zero, all remounted disks are eligible for preemptive 
demounting and library 1 operates in fixed mode. When 
Z is very large, disks are prevented from being preemp- 25 
tively demounted. In the preferred embodiment, Z is set 
between 0 and 120 seconds to maintain the proper bal- 
ance among these factors. 

While the invention has been described with respect 
to a preferred embodiment thereof, it will be under- 
stood by those skilled in the art that various changes in 
detail may be made therein without departing from the 
spirit, scope, and teaching of the invention. For exam- 
ple, while the invention has been disclosed in the con- 
text of an optical disk library, similar consideration may 
make it equally applicable to other types of libraries. In 
addition, numerous variations in the libraries may be 
made, such as the number of drives and storage cells. 
For example, in an alternative embodiment, library 1 
includes 32 storage cells 3 and two drives 4. System 
controller 17 is located external to housing 2, which is 40 
of reduced size. The remaining features of library 1 are 
essentially unchanged. Accordingly, the invention dis- 
closed herein is to be limited only as specified in the 
following claims. 



What is claimed is: 45 
I. A method for accessing data in a file stored on at 
least one of a plurality of removable data storage media 
in an automated storage library such that peripheral 
storage drives in the library are transparent to a host 
processor, the data storage media storing a plurality of 50 
volumes, one of the volumes including the file to be 
accessed, the automated storage library including a 
plurality of internal peripheral storage drives, a plural- 
ity of data storage media storage cells, automated means 
for transferring a data storage medium between the 55 
plurality of internal peripheral storage drives and the 
plurality of storage cells, and a controller coupled to 
each of the plurality of internal peripheral storage 
drives, the automated means, and the host processor, 
the controller storing the location within the library of 60 
each of the plurality of volumes, the method comprising 
the machine executed steps of: 
the controller receiving a request from a host proces- 
sor to access a file on a volume in the library, the 
request specifying the file, the volume, and the 65 
library; 

the controller determining the location within the 
library of the volume specified in the request; 
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the controller allocating at least one of the internal 
peripheral storage drives; 

the automated means transferring the volume speci- 
fied in the request to said at least one of the internal 
5 peripheral storage drives which has been allocated 
and mounting said volume therein; and 

the host processor, unaware in which of the internal 
peripheral storage drives that the volume specified 
in the request has been mounted read/write access- 
30 ing data in the file specified in the request via com- 
munications routed to said at least one of the inter- 
nal peripheral storage drives by the controller. 

2. The method of claim 1 wherein the request is in a 
format used by the host processor to access a file on a 

15 data storage medium mounted in a peripheral storage 
drive coupled to the host processor, with a specification 
of a peripheral storage drive coupled to the host proces- 
sor replaced with a specification of the library and a 
specification of a subdirectory in a peripheral storage 

2Q drive coupled to the host processor replaced with a 
specification of a volume in the library. 

3. An automated storage library capable of allowing 
access to data in a file stored on at least one of a plural- 
ity of removable data storage media therein such that 

25 peripheral storage drives in the library are transparent 
to a host processor, the data storage media storing a 
plurality of volumes, one of the volumes including the 
file to be accessed, the automated storage library com- 
prising: 

a plurality of internal peripheral storage drives; 

39 a plurality of storage cells; 

automated means for transferring a data storage me- 
dium between the plurality of internal peripheral 
storage drives and the plurality of storage cells; and 

a controller coupled to each of the plurality of inter- 
35 nal peripheral storage drives, the automated means, 
and the host processor, the controller storing the 
location within the library of each of the plurality 
of volumes, the controller including machine- 
executed means for: 

40 receiving a request from the host processor to access 

a file on a volume in the library, the request speci- 
fying the file, the volume, and the library; 
determining the location within the library of the 
volume specified in the request; 
45 allocating at least one of the internal peripheral stor- 
age drives; 

instructing the automated means to transfer the vol- 
ume specified in the request to said at least one of 
the internal peripheral storage drives which has 
50 been allocated and to mount said volume therein; 
and 

allowing the host processor, unaware in which of the 
internal peripheral storage drives that the volume 
specified in the request has been mounted to have 
55 read/write access to data in the file specified in the 
request by routing communications between the 
host processor and said at least one of the internal 
peripheral storage drives. 

4. The automated storage library of claim 3 wherein 
60 the request is in a format used by the host processor to 

access a file on a data storage medium mounted in a 
peripheral storage drive coupled to the host processor, 
with a specification of a peripheral storage drive cou- 
pled to a host processor repl aced with a specification of 
65 the library and a specification of a subdirectory in a 
peripheral storage drive coupled to the host processor 
replaced with a specification of a volume in the library. 
* * * * * 



1 5^ in a data storage subsystem having an automa ted storage 

2 library and a controller, said automated sto rage library 

3 including a plurality of storage dri ves, a plurality of 

4 storage cells, and an automated means for transferring at 

5 least one of a plurality of removable data storage media 

6 between said storage drives and said s torage cells, each of 

7 said removable data storage media s toring a plurality of 

8 volumes, each of said plurality of volumes including at 

9 least one file, said controller coupled to each of said 

10 storage drives, said automated means, a nd a host processor, 
ijj said controller storing a location within said autom ated 
lg storage library for each of said plural ity of volumes, a 

]j| method for accessing data from a selec ted file within said 

if automated storage library such t hat said storage drives are 

|5 transparent to said host processor, sa id method comprising 

11 the machine executed steps of: 

ft said controller receiving a reguest from said host 

jj processor to access said selected file w ithin said automated 

19 storage library, said reguest identifyi ng said selected 

20 file, a specified volume, and said automated storage 

21 library; 

22 said controller determining the location within said 

23 automated storage library of said sp ecified volume; 

24 said controller allocating at least one of sa id storage 

25 drives; 
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26 said automated means transferri ng said specified volume 

27 to said at least one allocated storage d rives, and mounting 

28 said specified volume therein; and 

29 said host processor, unaware in whic h of said storage 

30 drives that said specified volume ha s been mounted, 

31 read/write accessing data in said selected file via 

32 communications routed to said at least one allocated storage 

33 drives by said controller. 

1 6j_ The method of claim 5 wherei n said request is in a 

9 format used by the host processor to ac cess a file on a data 

J storage medium mounted in a stor age drive coupled to the 

% host processor, with a specificati on of a storage drive 

}| coupled to the host processor re placed with a specification 

L6 of the library, and a specifica tion of a subdirectory in a 

% storage drive coupled to the host processor re place d with a 

Ijg specification of a volume in the library. 

1 7^ A data storage subsystem coupled to a host processor, 

2 said data storage subsystem comp rising; 

3 an automated storage library allowing access to data in 

4 a file stored on one of a plurality of removable data 

5 storage media such that periphe ral storage drives in said 

6 library are transparent to said host processor, said data 

7 storage media storing a plurality of vo lumes, one of said 

8 plurality of volumes including said f ile to be accessed, 



5,388,260 



2 



9 said automatic storage library comprising: 

10 a plurality of peripheral storage drives; 

11 a plurality of storage cells; and 

12 an automated means for transferring at least one 

13 of a said data storage media between said peripheral 

14 storage drives and said storage cells; and 

15 a controller coupled to each of said peripheral storage 

16 drives, said automated means , and said host processor/ said 

17 controller storing a location within said library for each 

18 of said plurality of volumes/ said controller including 
W machine executed means for; 

W receiving a reguest from said host processor to 

%l access a selected file within said library/ said 

|^ reguest identifying said selected file, a specified 

23 volume/ and said library; 

jg4 determining the location within said library of 

w5 said specified volume; 

^6 allocating at least one of said peripheral storage 

27 drives; 

28 instructing said automated means to transfer said 

29 specified volume to said at least one allocated 

30 peripheral storage drives / and mounting said specified 

31 volume therein; and 

32 allowing said host processor/ unaware in which of 

33 said peripheral storage drives that said specified 

34 volume has been mounted/ read/write access to data in 
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35 said selected file by routing communicati ons to said at 

36 least one allocated peripheral st orage drive. 

1 8^ The data storage subsystem of claim 7 wher ein said 

2 request is in a format used bv the hos t processor to access 

3 a file on a data storage medium mounted in a storage drive 

4 coupled to the host processor, with a spec ification of a 

5 storage drive coupled to the host proc essor replaced with a 

6 specification of the library, and a s pecification of a 

7 subdirectory in a storage drive cou pled to the host 

j| processor replaced with a specification of a volume in the 

I library. 

4 9^ An article of manufacture for use in a data storage 

*_2 subsystem having an automated storage lib rary and a 

S3 c ontroller, said data storage subsyste m for accessing data 

1/4 in a file on one of a plurality of volumes stored within 

%5 said library such that peripheral storage drives within said 

6 library are transparent to a host proc essor coupled to said 

7 data storage subsystem/ 

8 said article of manufacture comprising a c omputer 

9 usable storage medium having a comput er readable program 

10 code embodied in said medium which may cause s aid controller 

II toj_ 

12 store a location within a plurality of sto rage cells 

13 for each of said plurality of volumes within said library; 
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14 receive a request from said host processor to access a 

15 selected file within said library, said reque st identifying 

16 said selected file, a specified volume, and said library; 

17 determine the location within said library of said 

18 specified volume; 

19 allocate at least one of said periphe ral storage drives 

20 within said library, said controller coupled to each of said 

21 peripheral storage drives; 

22 instruct an automated means within said library to 

23 transfer said specified volume from said l ocation within 
said plurality of storage cells to s aid at least one 

2| allocated peripheral storage drives , and mounting said 

jjj specified volume therein; and 

allow said host processor, unaware in whi ch of said 

2j peripheral storage drives that said s pecified volume has 

H been mounted, read/write access to dat a in said selected 

§0 file by routing communications to said a t least one 

. 

it. allocated peripheral storage drive. 
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BOX 7 

Assistant Commissioner of Patents 
Washington, D.C. 20231 

Sir: 

IBM Corporation (hereinafter "IBM"), through its duly 
authorized counsel, declares as follows: 

1. IBM is the assignee and owner of all right, title and 
interest of U.S. Patent No* 5,388,260 <" f 260 patent") 
for Transparent Library Management granted on February 
7 , 1995 to Christopher J. Monahan, et al. 

2. IBM believes that Christopher J. Monahan, Mary L. 
Monahan, Dennis L. Willson and Lee D. Willson are the 
joint inventors of the invention described and claimed 
in the U.S. Patent No. 5/388,260 and in the 
accompanying reissue application for U.S. Patent No. 
5,388,260, for which it now solicits a reissue patent; 
and 



1 



3. IBM, as assignee of the entire Interest in U.S. Patent 
No. 5,388,260, further offers to surrender the original 
♦260 patent upon allowance of the accompanying reissue 
application. 

The undersigned declares further that all statements made 
herein of his own knowledge are true and that all statements made 
on information and belief are believed to be true; and further 
that these statements were made with the knowledge that willful 
false statements or the like so made are punishable by fine or 
imprisonment, or both, under Section 1001 of Title 18 of the 
United States Code and that such willful false statements may 
jeopardize the validity of the accompanying applications or may 
reissue patent granted thereon. 
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